home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 001459_daemon _Sat Jun 26 23:50:31 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  4KB
  1. Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  2.     id AA02024; Sat, 26 Jun 93 23:50:33 MET DST
  3. Return-Path: <mvanheyn@cs.indiana.edu>
  4. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  5.     id AA02020; Sat, 26 Jun 93 23:50:31 MET DST
  6. Received: from moose.cs.indiana.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  7.     id AA17463; Sun, 27 Jun 1993 00:13:45 +0200
  8. Received: from localhost by moose.cs.indiana.edu
  9.     (5.65c/9.4jsm) id AA22627; Sat, 26 Jun 1993 17:13:41 -0500
  10. From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
  11. To: Rob Raisch <raisch@ora.com>
  12. Cc: www-talk@nxoc01.cern.ch
  13. Subject: Re: Suggestion for a new URL type 
  14. In-Reply-To: Your message of "Sat, 26 Jun 1993 15:59:37 -0400."
  15.              <Pine.3.03.9306261536.R5397-b100000@amber.ora.com> 
  16. Date: Sat, 26 Jun 1993 17:13:41 -0500
  17. Message-Id: <22625.741132821@moose.cs.indiana.edu>
  18. Sender: mvanheyn@cs.indiana.edu
  19.  
  20. Thus wrote: Rob Raisch
  21. >I strongly disagree.  The security issue is inherent in the network, not
  22. >in URLs. We should not attempt to scale some moral high ground simply to
  23. >stop up some possible security holes, which are not ours to stop up in the
  24. >first place. 
  25. >
  26. >The answer to insecure network services is to make them more secure, not
  27. >to limit the deployment and usefulness of URLs. 
  28. >
  29. >If a dedicated cracker wishes to break the system, I would suggest that
  30. >writing an HTML document, and using that as a lock pick on doors which
  31. >have no locks to begin with, would be a marvelous exercise in stupidity.
  32.  
  33. I believe we should have an attitude similar to that of MIME regarding
  34. security:
  35.  
  36. - Security is more important than interoperability
  37. - No additions should be made without a careful review of possible
  38.   security issues
  39. - User agents should present the user with sufficient information for
  40.   the user to avoid possible traps, and should do so in a way that
  41.   even a relatively inexperienced user can understand
  42.  
  43. Allowing an attacker to cause a victim to telnet to an arbitrary port
  44. on an arbitrary machine and send arbitrary data certainly has some
  45. potential risks.
  46.  
  47. Scenario:  Someone installs a document with a hyperlink that, when
  48. activated, causes bad mail (say, a death threat) to be mailed to the
  49. President of your organization/university/whatever.  You click on it.
  50. Depending on the implementation of the client, you may or may not see
  51. anything out of the ordinary, and you may or may not understand what
  52. it means.  If the attacker is clever, it's labeled something like
  53. "Click here to see some sample SMTP output."
  54.  
  55. Three days later, you are brought up on charges of mailing a death
  56. threat.  An investigation of transfer logs, RFC 931 authentication
  57. protocols, or whatever reveal that the message did come from your
  58. account/machine (which is correct; it *did*.)  You have no idea what
  59. happened.  Even if you did suspect a bad hyperlink, the offending HTML
  60. document has been changed (and may have even been rigged by the server
  61. to only look that way for you, and only once.)
  62.  
  63. That's just an offhand scenario.  It might also be possible to forge
  64. postings (including control postings that do damage, like sendsys or
  65. rmgroup or cancel) or muck with other widely used protocols.
  66.  
  67. Being able to do that kind of arbitrary URL referencing would have
  68. some advantages, and would lessen the need for gateways; this is good.
  69. My own inclination is that a client would have to take significant
  70. steps to reduce the risk of problems, and that the advantage of this
  71. kind of URL would be outweighed by the added inconvenience of users
  72. being warned of arbitrary transactions for approval (not to mention
  73. the trouble for client writers.)  That's just an inclination, though.
  74. I'd be interested in the results of a security review; maybe it's not
  75. as much a problem as I'm guessing.
  76.  
  77. - Marc
  78. --
  79. Marc VanHeyningen  mvanheyn@cs.indiana.edu  MIME, RIPEM & HTTP spoken here